ome-xml: java: Don't report unhandled links prematurely #128
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a second version of #81 but is Java-only and omits the C++ changes which are no longer applicable. Please also see the discussion on that PR.
This PR corrects some long-standing issues in the Java reference processing implementation.
OMEModelObject::link
implementations always chained up to their parent before handling the linking themselves. This works, but would result in the parent issuing a warning if it couldn't handle it, despite the child later handling the link. We now chain up only if the child can't handle the link, and issue a warning right at the top if nothing handled it. This solves a number of annoying Java model serialisation warnings which are completely bogus.In effect, you will see that setting an
AnnotationRef
onDetector
or any other element derived fromManufacturerSpec
will no longer haveManufacturerSpec::link
issue a bogus warning. This applies to any model object which is derived from another model object, e.g.LightSource
, where the reference is handled by the most derived type, or any derived type after the first, where the chaining up will trigger the spurious warning.For OMERO import, this should remove a large number of the bogus import warnings related to OME-XML metadata which we have seen on e.g. the QA system and other channels over the last few years.
LightSource
andShape
are notable culprits.Testing:
tiffinfo
ortiffcomment
ontest.ome.tiff
. Check that you get threeAnnotationRef
elements linking to the three annotations, demonstrating that the reference processing and subsequent serialisation worked correctly.metadata-formatwriter
, creating anAnnotationRef
onDetector
or similar. You'll see the warnings go when built against this ome-model snapshot, but otherwise no other functional changes.